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(57] ABSTRACT 

An information terminal unit with history management 
functions, wherein the user clicks on previous and later 
history buttons using a mouse. Clicking a history button 
causes a URL assigned with a version number to be created. 
The URL is sent to a relay server, which searches its cache 
for the requested data and, if the requested version is found, 
transfers that data back to the information terminal unit. This 
provides the user with a feasible method to access past data 
that may no longer exist in the desirable form. 
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INFORMATION TERMINAL UNIT WITH 
HISTORY MANAGEMENT FUNCTIONS 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to database technology and 
an information terminal unit with history management func- 
tions for searching for or acquiring data particularly from 
information providers, which are connected to each other via 
a network and configured as a distributed database system. 

2. Description of the Prior Art 

Conventional distributed database systems use the Inter- 
net via a plurality of information providers (servers). Most 
servers distributed throughout a database structure called the 
World Wide Web (WWW) on the Internet provide their own 
individual data that users on the information terminal unit 
end obtain when the need arises. 

Servers scattered throughout this WWW are linked 
together to form a distributed database using a mechanism 
called hyperlinks. Hyperlinks use indexes called uniform 
resource locators (URLs), contained in one data, or location, 
of the database, to point to other data in the database. Users 
follow these indexes to semi- automatically move to other 
servers and obtain data from those servers. 

These URLs are basically name references and do not 
themselves contain the essential content of the data pointed 
to by the hyperlinks. Therefore, the existence of a hyperlink 
does not necessarily guarantee the existence of the actual 
data to which the hyperlink points. 

Further, a feature of the distributed database system on the 
Internet is that the processing is not consistent throughout, 
but rather separate and individual processing is performed 
for each server. In general, the processes for creating links 
and for preparing data are different. In such a database 
system, specific data corresponding to a hyperlink will not 
always exist even if the hyperlink has been created. 

Hence, users of the database service have only been able 
to search or acquire data that is available at the time of use, 
because the servers used to provide the data service are not 
all consistent in processing. For example, data that could be 
found or acquired in the past is sometimes altered at another 
point in time. When this happens, a user wanting to search 
or acquire that past data cannot, but can now only access the 
current altered data. 

Since this past data cannot be accessed when the need 
arises, the user could save data onto a local disk while the 
data is still accessible, when the user thinks that data might 
be useful in the future. 

However, it is not feasible for all users to save all the data 
they will need, and a large memory capacity would be 
necessary to store all that data. Further, if a large amount of 
data is saved, much labor would be required to process that 
data, determining which data are necessary for the user. 

SUMMARY OF THE INVENTION 

In view of the foregoing, it is an object of the present 
invention to provide an information terminal unit for storing 
in a storing means data acquired from information providing 
means, allowing past data to be searched for and acquired 
according to the user's specifications. 

To achieve the above and other objects, there is provided, 
as shown in FIG. 1, an information management terminal 
unit connectable to a system wherein a plurality of infor- 
mation providing means are connected to one another via a 



)1,773 

2 

network, thereby configuring a distributed database system. 
The information management terminal unit includes com- 
municating means, history management mans, storing 
means, screen generating means, displaying means, and 

s history specifying means. The communicating means is 
provided for communicating with the plurality of informa- 
tion providing means via the network and acquiring data 
therefrom. The history management means manages, on a 
time basis, the data acquired from the information providing 

10 means. The storing means stores the data acquired from the 
plurality of information providing means. The screen gen- 
erating means generates screen information based on the 
data received from the historly management means. The 
displaying means displays an image screen based on the 

is screen Information generated by the screen generating 
means. The history specifying means is provided for speci- 
fying history information in the history managing means. 

According to the information terminal unit of the present 
invention, any one of the plurality of information providing 

20 means, with which a distributed database system is 
configured, is accessible with the communicating means via 
the network and data in a desired information providing 
means can be searched for and acquired. The history man- 
agement means manages, on a time basis, plural pieces of 

25 data acquired from the information providing means through 
the communicating means. The plural pieces of data are 
stored in the storing means and the screen generating means 
generates screen information based thereon. A screen image 
is generated based on the screen information and is dis- 

30 played on the displaying means. With such an arrangement, 
the data acquired from the information providing means and 
also the data stored in the storing means can be displayed on 
the displaying means. 
Because past data can be specified by the history speci- 

35 fying means, a user can easily obtain the past data only by 
operating the history specifying means. 

The history management means adds coded information 
to the data acquired from the plurality of information 

4Q providing means to provide coded information added data 
and stores the coded information added data in the storing 
means. The coded information identifies one of the plurality 
or information providing means from which the data is 
acquired. Because coded information is added to the data 

45 acquired from the information providing means and the 
resulting data is stored in the storing means, search for a 
desired data can be easily implemented. 

Plural sets of screen generating means, displaying means, 
and the history specifying means may be provided to one set 

50 of the history management means and the storing means. By 
such a configuration, a number of users can share the single 
storing means and so it is advantageous in conserving 
memory capacity. 
According to another aspect of the invention, there is 

55 provided a method of acquiring data from a plurality of 
information providers connected to one another via a net- 
work. First, a uniform resource locator is entered from one 
of a plurality of information terminal units connectable to 
the network to acquire data identified by the uniform 

60 resource locator from one of the plurality of information 
providers. The uniform resource locator includes a directory 
name and a file name. The data acquired from the informa- 
tion provider is stored in a directory of a cache memory. The 
directory is named to correspond to the uniform resource 

65 locator. The data stored therein is assigned with a file name 
and a version of the data. The data is transferred to any 
information terminal unit which searches for the data, and 
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the dai a is displayed in a display unit provided in association FIG. 5 is an explanatory diagram showing a sample 

with the information terminal unit when the data identified display; 

by the uniform resource locator is stored in the cache FIG. 6 is an explanatory diagram showing a URL; 

memory. pjG 7 j s a flowchart showing the processing sequence of 

The uniform resource locator further includes a version. 5 conventional terminals* 

The file name further includes a flag indicating that the CT ^ 0 . . . , m . . - ftf ,„„ 

- . , . jj.nr .1. • • • FIG. 8 is a block diagram showing the functions of relay 

version 01 the data is added. Preferably, the version is given . „ . 0 

, , . equipment; 

by a number corresponding to year/month/date at a time r 

when the uniform resource locator is entered. terlltoal e "i melt ^ functions of 

Whether or not the data identified by the uniform resource 30 * ennma e< T ai P ment ' 

locator is updated is investigated in the information provider nG - 10 is aD explanatory diagram of a version-assigned 

when the uniform resource locator is later entered from one URL; 

of the information terminal units. When the data identified FIG. 11(a) is an explanatory diagram showing the stroc- 

by the uniform resource locator is not updated, the data is ture of cache data; 

transferred to the information terminal unit which searches 15 FIG. 11(b) is an explanatory diagram showing the struc- 

for the data from the cache memory. When the data identi- ture of index file; 

fied by the uniform resource locator is updated, updated data FIG. 11(c) is an explanatory diagram showing the struc- 

is stored in the directory of the cache memory. The updated Q f cacnc fli c - 

data stored therein is assigned with a file name and a new ^ pjQ 12(a) ^ an explanatory diagram showirjg changes in 

version. ^ ata Qn servers over time; 

A desired version of the data can be entered when the data , t , . j4 

t t j * j . 1 j ■ 1 1 * + i FIG. 12(d) is an explanatory diagram showing cache data 

corresponding to the desired version is to be displayed in the ... w r ' to & 

j- 1 m the relay server; 

display unit. , . 

rrm j 4 . 4 . - c i * -j FIG. 13 is a flowchart showing the operations of relay 

The data contains another uniform resource locator iden- 25 & r j 

tifying correlated data. The another uniform resource locator <1 l P > 

includes a directory name and a file name. Another uniform FIG - 14 * a flowchart showing the procedure for writing 

resource locator is entered from the information terminal t0 the cacnc J 

unit to acquire the correlated data identified by the another FIG. 15 is a flowchart showing the processing sequence of 

uniform resource locator from one of the information pro- 3Q * terminal in the embodiment; and 

viders. The correlated data is also stored in a directory with FIG. 16 is a flowchart showing a procedure for searching 

the directory name of the another uniform resource locator the cache. 

of the cache memory. The correlated data stored therein is _ _ m 

also assigned with a file name and a version of the data. Hie ° E ™ L * » ™^™«^ HE 

correlated data is transferred to any one of the information 35 PREFERRED EMBODIMENT 

terminal units which searches for the correlated data. The a preferred embodiment of the present invention will be 

correlated data can also be displayed in the display unit of described while referring to the accompanying drawings, 

the corresponding information terminal unit when the cor- Information terminal units according to the embodiment 

related data identified by the another uniform resource are prov id e d with a history management function and used 

locator is stored in the cache memory. 4Q in a nctW0 rk system shown in FIG. 2. This network is 

Typically, the information terminal unit is connected to a configured by connecting local area networks (LAN) 11 to 

local area network. The plurality of information providers a wide area network (WAN) 14 as represented by the 

are connected to a wide area network. The local area Internet. Terminal units 13 for the users and a relay server 12 

network is connected to the wide area network. Preferably, are connected to the LAN 11. In the embodiment, an 

a relay server is connected to the local area network and the 45 information terminal unit having a history management 

cache memory is provided in the relay server. The relay function is configured by any one of the terminal units 13 

server acts as a server with respect to the information and the relay server 12. Servers A, B and C denoted by 

terminal unit on the local area network and as a client with reference numerals 15, 16 and 17, respectively, serve as 

respect to the plurality of information providers on the wide infonnation providers. Those servers and many WWW 

area network. 50 servers are connected to the WAN 14 to form a distributed 

BRIEF DESCRIPTION OF THE DRAWINGS database. 

^ . t c , , Ci , . A hardware arrangement of the network will be described. 

The particular features and advantages of the invention as „ T AKT1i * ... . • , - 

„ v . .... & c f „ Generally, the LAN 11 employs high speed communication 

well as other objects will become apparent from the follow- J l t v t . «; A m i,< i 

. . * . • ,i • fines, such as an Ethernet, whereas the WAN 14 employs 

ing description taken in connection with the accompanying „ . . ' . . , . t . „ 

fe . • u- u 55 relatively low speed but long distance communication lines, 

drawings, in which: such && telcphone lines Whi]e var } 0 us kinds of equipment 

FIG. 1 is an explanatory diagram showing an example &re fof ^ felay n m6 the uni(s 13 

structure of the present invention; (hc pfcsent embodimcnt uscs pcrs0 nal computers therefor as 

FIG. 2 is a block diagram of a network using information shown in FIG. 3. Briefly, as shown in FIG. 3(a), the relay 

terminal units of the embodiment with history management 60 servcr 12 i nc hjdes a network interface 21 serving as a 

functions; communication means, a central processing unit (CPU) 22 

FIG. 3(a) is a block diagram showing a hardware structure serving as a control means, a memory 23 serving as a storage 

of a relay server used in the embodiment; means, and a disk 24 also serving as a storage means. On the 

FIG. 3(b) is a block diagram showing a hard ware structure other hand, as shown in FIG. 3(b), the terminal unit 13 

of a terminal unit used in the embodiment; 65 includes a network interface 31 serving as a communication 

FIG. 4 is an explanatory diagram showing a sample means, a CPU 32 serving as a control means, a memory 33 

HTML file; serving as storage leans, a display unit 35 serving as a 
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display means, a keyboard 36 serving as an input means, and outline of the process described above as seen from the 

a mouse 37 also serving as an input means. terminal units 13 is shown in FIG. 7. 

Operation of the WWW system in this network will be The process shown in FIG. 7 is similar to that executed in 

briefly described. conventional systems not provided with history buttons 55 

The network uses TCP/IP (transmission control protocol/ 5 md 56 ( see nG - 5 )- ^ P rocess shown in FIG - 15 anc J 
internet protocol) as a communication protocol. This TCP/IP described later includes use of these history buttons 55 and 
allows communications to be performed between any of the 56 > which are a feature of me P resetU invention. For pur- 
units on the network. Hence, the terminal unit 13 is capable P oses of comparison, however, the conventional process will 
of directly communicating with the server A (15), server B be described in general with reference to FIG. 7. 
(16), and server C (17) on the internet. The WWW system 10 The user inputs the first URL via the keyboard 36 of a 
performs data communications primarily with the HTTP terminal unit 13 (step 71; hereinafter, step will be abbrevi- 
protocol. Although other protocols are usable, the embodi- ated as S). Data specified by this URL is read from server A 
ment employs only the HTTP protocol which operates as an ( 15 ) usin S the HTTP protocol (S72), analyzed (S73), and 
upper significant protocol with respect to the TCP/IP pro- displayed in a window (S74). If data that must be transferred 
tocol The HTTP protocol is relatively simple. Whenever a 15 separately, such as image data, exists, that data is transferred 
command is received from a client or terminal unit, the and displayed in the window. This process is performed for 
server responds, transferring one piece of data each time. a^ data on the HTML page (S75). 

For example, assume that the terminal unit 13 sends a When all data for one page has been transferred (S75: 

command "GET/index.html" to the server A (15). This yes), the process waits for input from the mouse 37 (S76). 

command requests that the file "index.html" on the server A 20 When the mouse 37 is clicked, the position of the mouse 

(15) be transferred to the terminal 13. In response to this cursor at that time is extracted S77). If the position obtained 

command, the server A (15) transmits the corresponding file, coincides with a hyperlink (S78: yes), the URL correspond- 

i.e., "index.html," to the terminal unit 13. ing to that area is extracted (S79). Returning to S72, the 

Tne HTTP protocol determines the data transfer method. P roccss for obtaining data from the server 15 is repeated. 

The contents of the data are written with hyper text markup 25 If the position of the mouse cursor when the mouse 37 is 

language (HTML). FIG. 4 shows a page written with clicked is not at a hyperlink (SIS: no), then the process 

HTML. In HTML, messages and commands are written in corresponding to that position is executed (S80), and the 

a text format. In FIG. 4, a portion inserted between "<" and process returns to S76. 

indicates a command. FIG. 5 shows an entire image In this way, the WWW system functions through com- 

displayed on the display unit 35 of the terminal, unit 14 (see 30 munication between the terminal unit 13 and server A (15). 

FIG. 3(b)) corresponding to the HTML indicated in FIG. 4. Generally, however, communication is not performed 

An "open" button 51, "go" button 52, "view" button 53, directly between the terminal unit 13 and server A (15), but 

"exit" button 54 and history buttons 55 and 56 are provided through the relay server 12. 

in the upper portion of the display. Clicking these buttons 35 The main purpose for using the relay server 12 is to store 

with the mouse 37 (see FIG. 3(b)) causes the corresponding the data in a cache to increase the apparent transfer speed, 

operations to be performed. The history buttons 55 and 56 In general, the LAN 11 is faster than the WAN 14. Therefore, 

are used to trace the history and extract past data. When the data is read and temporarily stored in the cache memory of 

left history button 55 is clicked, the previous version can be the relay server 12 on the LAN 11. When accessed again, the 

displayed whereas when the right history button 55 is 4Q data is transferred from the relay server 12 rather than from 

clicked, the following new version is displayed. server A (15) on the WAN 14, improving the effective access 

A scroll bar 57 is located at the right side of the display speed, 

shown in FIG. 5. In the central portion of the display is A feature of the present embodiment is to effectively 

located a main window in which actual data is displayed. search past data by introducing a history management 

Referring back to FIG. 4, "SAMPLE," sandwiched between 45 mechanism for data on the relay server 12. Here, the relay 

"<H1>" and "</Hl>," indicates a header whose characters server 12 of the present embodiment will be described with 

are of a larger size than the other displayed characters. The reference to FIG. 8. 

line <IMG SRC-"star.giP' > in FIG. 4 corresponds to the The relay server 12 includes a URL processing function 

star symbol 59 in the main window 58 shown in FIG. 5, and 83 for processing version -assigned URLS, to be described 

is a command to display an image file named "star.giP \ 50 later; a cache management function 84 for processing data in 

Therefore, a file containing this symbol is transferred sepa- the cache; a file system processing function 85 for actually 

rately using the HTTP protocol and put on the window. saving data; interface functions 81 and 82 for connecting to 

The lines "A HREF-"http://www.abc.net/index.htmr> the network; and a timer function 86 for managing the time. 

Hyper link</A>" describes a characteristic hyperlink in the The LAN network interface function 82 performs server 

WWW system. When the text portion between "<A. . . > and 5S operations for the terminal unite 13. The WAN network 

</A> is clicked by the mouse 37, the data designated by interface function 81 functions as a client for the servers 15, 

"HREF=. . . " can be read, causing users to feel as if they 16, and 17 on the WAN 14. 

have traveled from one server to another. FIG. 8 abstractly represents the functions of the relay 

The link indicated in "HREF= ..." is described in the server 12, but the functions are performed by the compo- 

form of a URL. A URL includes a protocol name 61, a host 60 nents shown in FIG. 3(a). For example, the WAN network 

name 62, and a path name (file name) 63, as shown in FIG. interface function 81 and LAN network interface function 

6. The protocol name is HTTP. The host name specifies a 82 are actually contained in the network interface 21 shown 

certain server on the TCP/IP network. The path name in FIG. 3(a). 

specifies a file on that server. The terminal units 13 also contain history functions. The 

In general, the servers in the WWW system simply send 65 terminal units 13 will be described with reference to FIG. 9. 

data specified by the terminal units 13, while the display and In addition to a network interface function 91, an HTML 

linking processes are performed in the terminal units 13. An processing function 96, a display function 99, a link Infor- 
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mation select function 97, a URL generation function 92, 
key input functions 93, and a mouse input function 98, 
which are necessary for demonstrating conventional client 
functions, the terminal units 13 of the present invention 
include a file management function 94 and version manage- 
ment function 95 for processing version-assigned URLs and 
history-assigned data. Naturally, the history buttons 55 and 
56 shown on the screen in FIG. 5 are an integral part of 
achieving the history functions of the present configuration. 

In order to achieve these history functions, the present 
embodiment employs data that has been slightly expanded 
from ordinary URLs and date. The configuration of this data 
will be described next. 

Version -assigned URLs are ordinary URLs with addi- 
tional data to indicate the version number. As shown in FIG. 
10, version-assigned URLs include a version flag 101 to 
indicate whether a version has been assigned; a version 
divider 102, a version number 103, a flag 104 to indicate the 
nearest version, a positive/negative offset 105 to indicate a 
version relative to the specified version number, and a 
normal URL 106 that is used conventionally. 

In the present embodiment, a date is used for the version 
number. For practical applications, the date would have to be 
more precise, as in units of seconds, but for simplicity of 
explanation only the date will be used in this example. 

The flag 104 is used when the specified version does not 
exist to indicate the nearest version to the one specified. 

A relative version some number of versions before or after 
a certain version can be specified by a "+" or "-" symbol and 
a number in the positive/negative offset 105. 

In the example of FIG. 10, the URL pointed to by (T) is 
version Sep. 20, 1995. The URL pointed to by (2) indicates 
the nearest version to version Sep. 20, 1995, this nearest 
version being one version newer. 

The format of data stored in the cache of the relay server 
12 will be described next. 

As shown in FIG. 11 (a), cache data is stored as files, each 
of which has a separate name devoted to one version of a 
URL. A directory 111 in the file system is create according 
to the protocol, host name, and path name, excluding the last 
part of the path name. The last part of the path name is used 
as the file name. 

The version number is then added at the end of the file 
name, since files having the same name could not be 
distinguished otherwise. An index file 112 is also created to 
indicate the newest file. The name for the index file 112 is 
created from the last part of the path name at the end of 
which is added "000". As shown in FIG. U(fc), a version 
number 114 of the latest version is stored in the index file. 

The cache files 113 contain, in addition to normal data, the 
total number of cache files 115 and the past versions 116, as 
shown in FIG. 11(c). However, since the total number of 
cache files will be the total number at the time the cache file 
was created, the older file versions do not necessarily 
indicate the correct total number. 

Next, the procedure for actually reading data and the 
operations of the history functions using the above compo- 
nents will be described. 

The example shown in FIG. 12 will be used for this 
description. First, a link is made from file a. html 121 on 
server A (15) to file b.html 122 on server B (16). Then, (1) 
the contents of file b.html 122 are revised, and at some later 
point in time, (2) the contents of file a.html 121 are revised. 
At this point, the Link that had been pointing to file b.html on 
server B (16) is changed to point at file c.html 123 on server 
C(17). 
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The process of reading file a.html 121 on server A (15), 
following a link to either server B (16) or server C (17), and 
reading either file b.html 122 or file c.html 123 will be 
described. 

5 First, the user reads file a.html 121 on server A (15). At 
this time, the same conventional operations (FIG. 7) are 
carried out in the terminal unit 13. In addition, data is stored 
in the cache of the relay server 12. This procedure will be 
described with reference to the flowchart in FIG. 13. 

10 When the URL is received from the terminal unit 13 
(S1301), the relay server 12 determines whether that URL 
has an assigned version number (S1302) If the URL is a 
normal URL without a version assigned (S1302: no), the 
cache coinciding with the URL is searched (S1303). Since 

15 cache data does not exist for data that is specified for the first 
time (S1304: no), the file a.html 121 is read from server A 
(15) (S1307). The data read is written to the cache (S1309) 
and then transmitted to the terminal unit 13 (S1310). 

2Q Here, the procedure in S1309 for writing data to the cache 
will be described with reference to the flowchart in FIG. 14. 

First a version number is created (S1401). Since the 
current date is used for version number in the present 
embodiment, the date is extracted using the timer function 

25 86 (FIG. 8). 

The directory and file names are extracted from the URL 
(SI 402). In this case, the directory is "http/A," and the file 
name is "a.html." A search is made for an index file within 
the directory (S1403). Since obviously no index file exists 

30 on the first access (S1404: no), a new index file is created 
in the directory (SI 407). Further, a new data cache file 126 
is created (S1408), as shown in FIG. 12(b). Version data is 
added to the data cache file 126 (S1409), and the data is 
written in the cache file (SI 410). 

35 If this data is accessed again, an older version of the file 
may exist in the cache. In this case, an index file already 
exists (SI 404: yes), so a new data cache file is created in the 
directory (S1405). The header of the file one version pre- 
vious to the new file is copied to the new file (S1406). Then, 

40 the new version number is added (S1409). Hence, each 
cache file contains all the version information from the 
previous files. 

After relaying the file a.html 121 from server A (15) 
shown in FIG. 12, the user clicks with the mouse 37 on a link 
45 described in the file a.html 121 to request the file b.html 122 
from server B (16). A process similar to the one just 
described is executed to transfer the file b.html 122 from 
server B (16) and write the data to the cache of the relay 
server 12. 

After some time passes, it will be assumed that the file 
b.html 122 is updated, for the sake of this example. Here, the 
process executed when the user again follows the procedure 
of accessing first server A (15) and then server B (16) will 
55 be described. 

For this case, the cache is searched (S1303) and the data 
is found to exist (S1304: yes), as shown in FIG. 13. Then the 
data is checked to see whether it has been updated (S1305). 
This is accomplished by inquiring to server A (15) whether 
60 the file a.html 121 has been updated. 

In this case, the data on server A (15) has not been updated 
(S1306: no), so the data of data cache file 126 shown in FIG. 
12(b) is read (S1308) and transferred to the terminal unit 13 
(S1310). 

65 Next, the user follows a link from the file a.html 121, as 
described above, to request data from server B (16), and the 
file b.html 122 is received from server B (16) according to 
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the procedure described above. In this case, the data has However, if in the process of FIG. 16 the URL was 

been updated (S1306: yes), so the new data is received from "@@@*951010*+l*http://B/b.htmI " the version 951010 

server B (16) (S1307). After writing the data to the cache also exists (S1605: yes), but a plus is specified in the URL 

(51309) , the data is transferred to the terminal unit 13 (S1609: yes). Hence, a search is performed for data one 

(51 3 10) . S version newer than the version 951010 (S1610). However, 
The processes described thus far have been achieved by no such data exists in the cache (SI 611: no), and the cache 

conventional relay servers with cache functions. Here, a searching process ends, having determined thai the data does 

process for extracting past data, which is a feature of the ao t exist in the cache. 

present invention, will be described. Therefore, returning to S1312 of FIG. 13, since the data 

The screen display of the terminal units 13 in the present 10 does not exist in the cache (S1312: no), the relay server 12 

embodiment is shown in FIG. 5. As described above, the sends an error message to the terminal unit 13 signifying that 

history buttons 55 and 56 are used to trace back through past no fik of that version exists (S1313). 

versions to extract older data By clicking on the left button the ^ - s rcceived ^ ^ ^ 

55 a version one earlier than the currently ^ d^played version terminal data m ^ 

will be displayed. By clicking on the right button 56, a ' _ T _ ,, /1A . r • ■ a ,u 

version one later than the currently displayed version will be 15 35 ( scc i FIG ; W>)> but if an error message is received, the 

displayed terminal unit 13 notifies the user concerning the error. 

The operations of the terminal unit 13 and relay server 12 In lhis wa * the user can lrace th ™S h P ast file versions 

when using the history buttons 55 and 56 will be described to find a specific version simply by clicking the history 

using the example of the file b.html 122 on server B (16) (see buttons 55 and 56 with the mouse 37. 

FIG. 12(a)). 20 In accessing past files by specifying versions, the treat- 

The flowchart shown in FIG. 15 is the same process ment of links is also different from the conventional method, 

shown in FIG. 7, except the operations related to the history That is, links to past data existed at a time in the past and do 

functions have been added. The process from S1501-S1503 not necessarily exist in the present. 

is the same as S71-S73 of FIG. 7. Next, after the entire page As one example, a link in the file a.html 121 of server A 

of file b.html 122 has been displayed on the screen of the 25 ^ ^ ^vised, ^ indicated in (2) of FIG. 12(a), to indicate 

terminal unit 13 (S1505: yes), the process waits for a mouse the file c html 12 3 on server C (17) instead of the file b.html 

click (S1506). 122 0 n server B (16). 

When the user clicks on one of the history buttons 55 or First> a s{ tQ fead thc fi]e a html m fe sem tQ servcr 

56, the position of the mouse cursor at the time of the click A (15) frQm ^ ^ 13 fa ^ ^ fi]e a Mm{ 

is input via the mouse input function 9 8 (see MG. 9), and the 30 * ' , . , ™ P , A u *u 

y. . 4 , /o-t*/\-j\ rr.L V j * 121 has been revised. Therefore, as described above, the 

position is extracted (S1507). If the position corresponds to . iL C1 ' . , ini r A 

oneof the history buttons 55 or 56 (S1508: yes),aURLfor f% server 12 receives the file a.html 121 froni i server A 

the version indicated is generated (S 15 10) by adding the (15), stores the data in the cache, and transfers the data to the 

version number to the normal b.html data. terminal unit 13. 

As described above, the data contains all version data up 3 5 ^ terminal UIlit 13 displays the data it receives. If the 

to the time the data cache file was created. Therefore, when ^ clic ks on a hyperlink, requesting the file c.html 123 

changing to data one version earlier, the earlier data can be from server C (17), the same procedure as described above 

extracted according to version data in the data currently is executed. Now, assume the user returns the display to the 

displayed. In other words, "@@@* 95091 0*http://B/ screen corresponding to the file a.html 121 and clicks on the 

b.html." Data one version later can be specified by adding 4p history buttons 55 to request the previous version. As 

"+1" to the version number of the currently displayed data, described above, the previous version of the file a.html 121 

as in "@@@*951010*+l*http://B/b.html. w is received and displayed. 

Next, the terminal unit 13 transfers this URL to the relay Now assume the user clicks on a hyperlink in this previ- 

server 12 and receives the data for the corresponding ver- ous version, requesting the file b.html 122 from server B 

sion. As shown in FIG. 13, after receiving a URL, the relay 45 (16). In the terminal unit 13, a URL is generated by adding 

server 12 checks whether the URL has an appointed version the flag 104 (see FIG. 10) specifying the nearest version to 

number (S1302). In this case, the URL has a version number the version of the file a.html 121. In other words, a request 

(S1302: yes), and the cache is searched, as a result. for "@@@* 950910* A*http://B/b.htmr is sent to the relay 

The process for searching the cache in S1311 will be server 12. The flag 104 is used because the version of the file 

described next with reference to the flowchart in Fig 16. 50 a.html 121 does not perfectly agree with the version of the 

If the URL is "@@@*950910*http://B/b.html," for file b.html 122. If the flag 104 is not added, the correspond- 

example, the directory and file names are extracted from the ing version cannot be retrieved. 

RL (S1601). The index file is searched for in the directory When receiving a URL containing a flag 104, the relay 

(SI 602). Since an index file exists in this case (S1603: yes), server 12 searches the cache in the same way as described 

the version data is extracted from the newest cache file 55 above. This process is the same as the process for searching 

(SI 604). The existence of the specified version is deter- the cache without a flag 104, as described in S1601-S1604 

mined from the version data SI 605). In this case, the version of FIG. 16, including searching for the index file according 

950910 exists in the version data (S1605), and the process to the file and directory names and extracting the version 

shifts to S1609. number from the most recent file. 

Here, the existence of a + or - specification is determined 60 However, if a file for the specified version does not exist 

(SI 609). Since no such specification is included in this URL (SI 605: no) and a flag 104 has been included (S1607: yes) 

(SI 609: no), the cache searching process ends, having the nearest version is extracted (SI 608). Here, the nearest 

determined that the data exists in the cache. version is the cache file that contains a version number 

Therefore, returning to S1312 of FIG. 13, the data exists closest to the version number specified, 

in the cache (S1312: yes), so the data is extracted from the 65 In this way, the file b.html 122, which is the nearest 

cache (S1308) and transferred to the terminal unit 13 version to the older file a.html 121, is extracted from the 

(SI 3 10). cache and transferred to the terminal unit 13. 
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If ihe file is frequently updated, the data extracted based 
on the link from the file a. html 121 will not always be the 
same as the one previously accessed. However, the user can 
easily go back or forth several versions using the history 
buttons 55 and 56 in order to find the desired version. 

While only one exemplary embodiment of this invention 
has been described in detail, those skilled in the art will 
recognize that there are many possible modifications and 
variations which may be may in this exemplary embodiment 
while yet retaining many of the novel features and advan- 
tages of the invention. Accordingly, all such modifications 
and variations are intended to be included within the scope 
of the appended claims. 

For example, as described in the above embodiment, the 
information terminal unit with history management func- 
tions was configured with the relay server 12 and any one of 
the terminal units 13, as shown in FIG. 2, but this informa- 
tion terminal unit could be configured as one unit perform- 
ing the functions of both. However, in the configuration 
described in the embodiment, a plurality of terminal units 13 
can use the history management functions and memory 
functions in the relay server 12, which is advantageous in 
conserving memory capacity, 

Further, in the embodiment described above, versions 
were specified by clicking on the history buttons 55 and 56 
using the mouse 37, but versions could be specified by 
clearly entering version-assigned URLs via the keyboard 36 
(see FIG. 3(b)). Also, since data for past versions is stored 
in cache files, these files could be displayed on the display 
unit 35 in a menu format, allowing the user to select a 
specific version. 

Further, when the contents of the cache files are changed, 
the changes usually pertain to only one portion of the data. 
Therefore, rather than storing the entire data for each 
version, only the portion differing from a past version could 
be extracted and stored in the cache, allowing the memory 
capacity of the disk 24, shown in FIG. 3(a) to be reduced. 

What is claimed is: 

1. An information management terminal unit connectable 
to a system wherein a plurality of information providing 
means are connected to one another via a network, thereby 
configuring a distributed database system, the information 
management terminal unit comprising: 

communicating means for communicating with the plu- 
rality of information providing means via the network 
and acquiring contents data from at least one of the 
plurality of information providing means, the contents 
data being identified by a URL; 

storing means for storing the URL and contents data 
acquired from the at least one of the plurality of 
information providing means; 

history management means for generating history infor- 
mation on the contents data stored in the storing means 
to manage the contents data on a time basis; 

specifying means for specifying the contents data based 
on the history information: 

screen generating means for generating screen informa- 
tion based on the contents data specified by the speci- 
fying means; 

displaying means for displaying an image screen based on 
the screen information generated by the screen gener- 
ating means; 

input means for inputting a data name, the data name 
being inputted by an operator on a needed basis; 

determination means for determining whether or not 
contents data identified by the data name is stored in the 
storing means; and 
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investigating means for investigating whether or not the 
contents data identified by the data name is updated in 
one of the plurality of information providing means 
from which the contents data stored in the storing 
means has been downloaded, wherein the communica- 
tion means acquires updated contents data when the 
contents data is updated in the one of the plurality of 
information providing means. 

2. The information management terminal unit according 
to claim 1, wherein the history information generated by the 
history management means includes coded information 
relating to the contents data, the coded information identi- 
fying the at least one of the plurality of information provid- 
ing means from which the contents data is acquired. 

3. The information terminal unit according to claim 1, 
wherein plural sets of screen generating means, displaying 
means, and the history specifying means are provided to one 
set of the history management means and the storing means. 

4. A method of acquiring data from a plurality of infor- 
mation providers connected to one another via a network, 
comprising the steps of: 

entering a uniform resource locator from one of a plurality 
of information terminal units connectable to the net- 
work to acquire contents data identified by the uniform 
resource locator from one of the plurality of informa- 
tion providers, the uniform resource locator including a 
directory name and a file name; 

assigning the contents data with a version of the contents 
data; 

storing the contents data with the file name of the uniform 
resource locator and the version of the contents data in 
a corresponding directory of a cache memory, the 
corresponding directory having the same name as the 
directory name of the uniform resource locator: 

transferring the contents data from the corresponding 
directory of the cache memory to any one of the 
plurality of information terminal units which searches 
for the contents data if the contents data is stored in the 
corresponding directory; and 

displaying the contents data transferred from the corre- 
sponding directory in a display unit provided in asso- 
ciation with the any one of the plurality of information 
terminal units. 

5. The method according to claim 4, further including the 
step of assigning the uniform resource locator with the 
version of the corresponding contents data. 

6. The method according to claim 5, further including the 
step of adding a flag to the file name, the flag indicating that 
the version of the data is assigned to the corresponding 
contents data. 

7. The method according to claim 5, wherein the version 
of the contents data is assigned by a number corresponding 
to year/month/date when the uniform resource locator is 
entered. 

8. The method according to claim 5, further comprising 
the steps of: 

investigating whether or not the contents data identified 
by the uniform resource locator has been updated in the 
one of the plurality of information providers from 
which the contents data stored in the corresponding 
directory has been downloaded when the uniform 
resource locator is later entered from any one of the 
plurality of information terminal units; 

when the contents data identified by the uniform resource 
locator has not been updated, transferring the contents 
data from the corresponding directory to the any one of 
the plurality of information terminal units; and 
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when the contents data identified by the uniform resource 
locator has been updated, acquiring updated contents 
data from the one of the plurality of information 
providers, assigning the updated contents data with a 
new version of the contents data, and storing the 
updated contents data, the newer version of the con- 
tents data and the file name in the corresponding 
directory of the cache memory. 

9. The method according to claim 8, further comprising 
the step of entering the file name with a desired version of 
the contents data when the contents data corresponding to 
the desired version is to be displayed in the display unit. 

10. The method according to claim 4, wherein the con- 
tents data contains another uniform resource locator identi- 
fying correlated contents data, the another uniform resource 
locator including another directory name and another file 
name, and further comprising the steps of: 

entering the another uniform resource locator from the 
one of the plurality of information terminal units to 
acquire the correlated contents data identified by the 
another uniform resource locator from one of the 
plurality of information providers; 

assigning the correlated contents data with another ver- 
sion of the correlated contents data; 
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storing the correlated contents data, the another version of 
the correlated contents data, and the another file name 
in a corresponding directory of the cache memory; 

transferring the correlated contents data from the corre- 
sponding directory of the cache memory to any one of 
the plurality of information terminal units which 
searches for the correlated contents data if the corre- 
lated contents data is stored in the directory; and 

displaying the correlated contents data in the display unit 
provided in association with the any one of the plurality 
of information terminal units. 

11. The method according to claim 10, wherein the 
information terminal unit is connected to a local area 
network, and the plurality of information providers are 
connected to a wide area network, the local area network 
being connected to the wide area network. 

12. The method according to claim 11, wherein a relay 
server is connected to the local area network and the cache 
memory is provided in the relay server, the relay server 
acting as a server with respect to the information terminal 
unit on the local area network and as a client with respect to 
the plurality of information providers on the wide area 
network. 
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